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Foreword 

This Technical Specification (TS) has been produced by the 3^^ Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the stage 2 and stage 3 description of the non realtime Multimedia Messaging Service, 
MMS. Stage 2 identifies the functional capabilities and information flows needed to support the service described in 
stage 1. 

The present document includes information applicable to network operators, service providers and terminal, switch and 
database manufacturers. 

The present document contains the core functions for a non realtime Multimedia Messaging Service, MMS, which are 
sufficient to provide a basicservice. 

MMS uses a number of technologies to realise the requirements of the stage 1 description (3G TS 22.140) [1]. The 
present document describes how the service requirements are realised with the selected technologies. As far as possible 
existing protocols (e.g. WAP, SMTP, ESMTP as transfer protocols; lower layers to provide push, pull, notification) and 
existing message formats (e.g. SMIL, MIME) shall be used for the realisation of the Multimedia Messaging Service. 

This specification serves as a foundation for the development of MMS for release 99. It describes a new service which 
has no direct equivalent in the previous ETSI/GSM world or in the fixed network world. In consequence readers may 
find that certain aspects are not clearly defined or open to misinterpretation. Where any such case is encountered it is 
essential that the issue is brought to the 3GPP TSG T2 standards body (see page 2 for contact information) for 
discussion and resolution in order to provide interoperable implementations in release 99. 
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EMA Electronic Message Association 

E-Mail Electronic Mail 

HTTP Hypertext Transfer Protocol 

lANA Internet Assigned Numbering Authority 

IETF Internet Engineering Task Force 

IMAP4 Internet Message Access Protocol 

GW Gateway 

MIME Multipurpose Internet Mail Extensions 

MM Multimedia Message 

MMSE Multimedia Message Service Environment 

MMS Multimedia Messaging Service 

MTA Mail Transfer Agent 

PDU Protocol Data Unit 

POPS Post Office Protocol Version 3 

RDF Resource Description Format 

RFC Request for Comments 

SMIL Synchronised Multimedia Integration Language 

SMPP Short Message Peer-to-Peer Protocol 

SMTP Simple Mail Transfer Protocol 

UA User Agent 

UAProf User Agent Profile 

URI Uniform Resource Identifiers 

VPIM Voice Profile for Internet Mail 

W3C WWW Consortium 

WAP Wireless Application Protocol 

WIM WAP Identity Module 

WML Wireless Markup Language 

WSP WAP Session Protocol 

WTLS Wireless Transport Layer Security 
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4 

4.1 



General Architecture 



Overview 




Figure 1 : General view of MMS provision within the different networks 

Figure 1 shows a generalised view of the Multimedia Message Service architecture for a third generation messaging 
system. It shall combine different networks and network types and shall integrate messaging systems already existent 
within these networks. The terminal operates with the Multimedia Messaging Service Environment, MMSE. This 
environment may comprise 2G and 3G networks, 3G networks with islands of coverage within a 2G network and 
roamed networks. The MMSE provides all the necessary service elements, e.g. delivery, storage and notification 
functionality. These service elements may be located within one network or distributed across several networks or 
network types. 
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4.2 



Involved MMS Elements 



Figure 2 shows that multimedia messaging may encompass many different network types. The basis of connectivity 
between these different networks shall be provided by the Internet protocol and its associated set of messaging 
protocols. This approach enables messaging in 2G and 3G wireless networks to be compatible with messaging systems 
found on the Internet. 
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Figure 2: MMS Architectural Elements 



MMSE 



The Multimedia Message Service Environment encompasses all the various elements that provide a complete MMS to a 
user. In the case of roaming the visited network is considered a part of that user's MMSE. However, subscribers to the 
mobile network B are considered to be a part of a separate MMSE. 

MMS Relay and MMS Server 

The MMS Server is responsible for storage and handling of incoming and outgoing messages. Associated with the 
MMS Server, is the MMS Relay which is responsible for the transfer of messages between different messaging systems. 
Depending on the business model, the MMS Server and the MMS Relay may be combined, separate or distributed 
across different domains. 

The MMS Relay should be able to generate charging data (CDR) when receiving MMs or when delivering MMs to the 
MMS User Agent or to another MMSE. 

MMS User Databases 

This element may be comprised of one or more entities that contain user related information such as subscription and 
configuration (e.g. user profile, HLR). 
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MMS User Agent 

The User Agent resides on a UE or on an external device connected to a UE. It is an application layer function that 
provides the users with the ability to view, compose and handle MMs (e.g. sending, receiving, deleting of MMs). 



4.3 



Protocol Framework 
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Figure 3: Protocol Framework to provide MMS 

To provide implementation flexibility, integration of existing and new services together with interoperability across 
different networks and terminals, the MMS shall make use of the protocol framework outlined in figure 3. In this 
framework the MMS User agent communicates through the MMS Relay with the MMS Server. This MMS Relay shall 
provide convergence functionality between server and MMS user agent and thus enabling the integration of different 
server types across different networks. It should be possible to combine Server and Relay functionality. 

Details for implementation of the MM transfer protocol A using WAP [3] or applications conforming to MExE [4] 
(e.g. Java and TCP/IP) are elaborated within this specification. The WAP implementation option is described in 
clause 7. Implementations based on applications using MExE may be defined in detail in future releases. Other 
implementations (e.g. using other standardised Internet protocols) are not defined in this specification in this release. 



4.4 Addressing 



MMS shall support the use of E-Mail addresses (RFC 822) [5]or MSISDN to address the recipient of a MM. In the case 
of E-Mail addresses standard internet message routing should be used. 

The usage of MSISDN for addressing a recipient in a different MMS service providers domain shall be possible. For 
that the need of MSISDN translation to a routable address has been identified. The mapping for the MSISDN to the 
correct recipient's MMS Relay or Server is left for standardisation in future releases. In the mean time, it is expected 
that MMS service providers or network operators will develop solutions for their particular needs which may include 
static tables or other look-up methods. 

Extensibility of the addressing framework is the goal and the specific mechanism is left for future releases. 
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5 Functional Description of Involved MMS Elements 

5.1 MMS User Agent 

5.1 .1 MMS User Agent operations 

The MMS User Agent shall provide the following application layer functionalities :- 

the MM composition; 

the MM presentation; 

the presentation of notifications to the user; 

the retrieval of MMs (initiate MM delivery to the User Agent). 
The MMS User Agent may provide additional application layer functionalities such as:- 

the signing of an MM on an end-user to end-user basis; 

the decryption and encryption of a MM on an end-user to end-user basis; 

all aspects of storing MMs on the terminal and/or USIM; 

the handling of external devices; 

the user profile management. 
This optional list of additional functionalities of the MMS User Agent is not exhaustive. 

5.1 .2 Minimum set of supported formats 

Multiple media elements shall be combined into a composite single MM using MIME multipart format as defined in 
RFC 2046 [6] . The media type of a single MM element shall be identified by its appropriate MIME type whereas the 
media format shall be indicated by its appropriate MIME subtype. 

In order to guarantee a minimum support and compatibility between multimedia messaging capable terminals, the 
following media formats shall be at least supported. 

Minimum set of supported media type Text formats:- 

plain text. Any character encoding (charset) that contains a subset of the logical characters in Unicode [7] 
shall be used (e.g. US-ASCII [8], ISO-8859-l[9], UTF-8[10], ShiftJIS, etc.). 

Unrecognised subtypes of "text" shall be treated as subtype "plain" as long as the MIME implementation knows how to 
handle the charset. Any other unrecognised subtype and unrecognised charset shall be treated as 
"application/octet - stream". 

In order to guarantee SMS interoperability, SMS 3G TS 24.011 [11] RP-DATA RPDU encapsulation defined in 
subclause 7.3.1 shall be supported. MIME type application/x-sms shall be used for this purpose. 

NOTE: SMS MIME type shall be used as soon as the MIME registration has been completed. 

To ensure interoperability with formats widely used e.g. in the internet community the support of the following formats 
or codecs is suggested: - 

Suggested formats or codecs for media type Audio :- 

- AMR [12]/ EFR; organised in octet format as specified in 3G TS 26.101 and 3G TS 26.101 Annex A [13] 

- MP3 [14] 

- MIDI [15] 

- WAV [16] 

Suggested formats or codecs for media type Image :- 
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- JPEG [17]. 

- GIF 89a [18]. 

Suggested formats or codecs for media type Video :- 

- MPEG 4 (Visual Simple Profile, Level 1) [19]. 

- ITU-T H.263 [20]. 
Quicklime [21]. 

5.2 MMS Server 

The MMS Server is responsible for storage and handling of messages. Several Servers can be included within an 
MMSE, e.g. MMS-Server, E-Mail Server, SMS Server (SMSC), Fax. 
NOTE: Several Eexamples can be found in Annex A. 



5.3 MMS Relay 



This MMS Relay shall provide convergence functionality between server and user agent and thus enable the integration 
of different server types across different networks. It should be possible to combine Server and Relay functionality. 

The MMS Relay is responsible for the following functions :- 

receiving and sending MM; 

enabling/disabling MMS function; 

personalising MMS based on user profile information; 

MM deletion based on user profile or filtering information; 

media type conversion; 

media format conversion; 

message content retrieval; 

MM forwarding; 

screening of MM; 

negotiation of terminal capabilities; 

checking terminal availability; 

MM notification to the MMS User Agent; 

generating charging data records (CDR); 

address translation. 

5.4 MMS User databases 

The MMS User databases may consist of e.g. user profile database, subscription database, HLR. 
The MMS User databases shall pro vide: - 

MMS user subscription information; 

information for the control of access to the MMS; 

information for the control of the extent of available service capability (e.g. server storage space); 

a set of rules how to handle incoming messages and their delivery; 
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information of the current capabilities of the users terminal. 
NOTE: The location of the User Databases and the access to them are out of the scope of Release 99. 



MMSE Interfaces 



6.1 



Involved MMSE Interfaces 



Figure 4 shows the Involved MMSE Interfaces that are further described below. 



MMS User 
Agent 




"Foreign" 
MMS 
Relay 




MMS 

Relay 




MMS 

Server #1 
(e.g. E-Mail) 



MMS 

Server #2 
(e.g. Fax) 



MMS 

Server #N 



Figure 4: MMSE Interfaces 



6.2 MMS Relay - MMS User Agent 

Details for implementation of the MM transfer protocol A using WAP [3] or applications conforming to MExE [4] 
(e.g. Java and TCP/IP) are elaborated within this specification. The WAP implementation option is described in 
clause 7. Implementations based on applications using MExE may be defined in detail in future releases. Other 
implementations (e.g. using other standardised Internet protocols) are not defined in this specification in this release. 

6.3 MMS Relay - MMS Server 

This interface shall be based upon existing standards e.g. HTTP or SMTP. Several examples of the MMS Relay and 
MMS Server interfaces can be found in Annex A. 

Where the MMS-Relay and MMS-Server are wholly integrated then the interface is outside the scope of the 
specification. 

NOTE: In future releases that separation of MMS Relay and MMS Server from a functional prospective may be 
defined. At that time architectural and protocol information is to be provided. 

6.4 MMS Relay - MMS User Databases 

This interface is outside the scope of this specification. 
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6.5 MMS Relay -HLR 

This interface may be used to provide information to the MMS Relay about the subscriber. If this interface is 
provisioned then it shall use existing MAP operations (e.g. procedures for determining the location of the mobile, 
procedures for alerting SMS service centres). Future releases may elaborate this area further. 

In case of using SMS as the bearer for notification this interface is not necessary. 

6.6 Interworking of different MMSEs 

The MMS Relay - MMS Relay interface is used to transfer MMs between different MMSEs. Interworking between 
different MMSEs shall be based on SMTP according to RFC 821 [22] as depicted in figure 5. 
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Figure 5: Interworking of different MMSEs 

All elements of an MM shall be included within a single SMTP message which shall be organised as MIME type 
application/multipart. All MM elements shall be of standard MIME content types including the MMS header. 

This MMS header shall be of registered MIME application class content type. It shall be sent as a distinct part of the 
SMTP message. In addition to this all header fields but the MMS specific header fields shall be copied into the SMTP 
message's header fields. 

When conveying an MM the MMS header part shall not be the primary part in the MIME so that non-MMS -aware 
readers can view this part as merely an attachment. This will minimise problems with presentations of the MM data by 
these readers. 

NOTE: Content type application/mmsheader is subject to registration within I AN A. In the mean time content type 
application/x-mmsheader shall be used to indicate the MMS header. 

NOTE: Private agreements may utilise additional connection and security (e.g. IPSec) methods. Such methods are 
out of the scope of standardisation for R'99. 



7 



WAP Implementation of MMS 



WAP provides significant support for MMS, both in direct service specification and in the underlying technologies. 
While the WAP MMS service specification work is new and is therefore unavailable for direct reference, its basic 
approach and limitations are based on WAP documents describing MMS architecture and message encapsulation. This 
should be done based on the underlying WAP technologies that have been published, and can therefore be referenced. 

7.1 WAP Protocol Framework 

In reference to subclause 4.3, the protocol framework applied to WAP implementation of MMS is provided in figure 6. 
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Figure 6: Protocol Framework applied to WAP implementation of MMS 



7.2 



WAP Architectural Support for MMS 



WAP support for MMS is based upon the services of its supporting technology. Therefore, the scope of WAP, as it 
addresses MMS, is as shown in figure 7. It does not cover activities or network elements beyond those shown and no 
such dependencies or expectations should be inferred or implied. 

Figure 7 shows an MMS Relay which in the WAP architecture's terminology is referred to as an MMS Server. The 
WAP architecture also refers to the MMS User Agent as an MM Client. These cover equivalent functionalities. 
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Figure 7: Scope of WAP Support for MMS 

Figure 7 shows two links. The first, between the wireless MMS User Agent and the WAP Gateway, is where the "WAP 
Stack" is used to provide a common set of services over a variety of wireless bearers. For application oriented services, 
like MMS, the interest is primarily in services offered by WAP Session Protocol (WSP) [23]. 

The second link connects the WAP Gateway and the MMS Relay. In the WAP architecture the MMS Relay is 
considered an Origin Server. These entities are connected over an IP network such as the Internet or a local Intranet. 
HTTP is used for data transfer and data can be originated from either entity. 

End-to-end connectivity, for the MMS application, between the wireless MMS User Agent and the MMS Relay is 
accomplished by sending data over WSP and HTTP. This is accomplished using the WSP/HTTP POST method for data 
originating at the wireless MMS User Agent and by using the WAP Push Access Protocol [24] in the other direction. 

The WAP Gateway, which enables the needed interworking, should not modify the data transfer via these transactions. 

The WAP view of MMS is constrained to the interactions between the MMS User Agent and the MMS Relay. It makes 
no representations as to services that are provided to or required of any other network elements. 
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7.3 WAP Transaction Flows Supporting MMS 

NOTE: The WAP MMS work is ongoing and the descriptions in this section are based upon preHminary material 
that is expected to remain stable. 

The WAP MMS work describes the end-to-end transactions that occur between the MMS User Agent and the MMS 
Relay. These transactions accomplish the following services: 

• MMS User Agent originates a Multimedia Message (MM). 

• MMS Relay notification to an MMS User Agent about an available MM. 

• MMS User Agent retrieving an MM. 

• MMS User Agent support for retrieval acknowledgement to MMS Relay. 

• MMS Relay sending delivery report to MMS User Agent. 

Figure 8 shows an example transaction flow illustrating a message origination, delivery and delivery report. 
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Figure 8: Example MMS Transactional Flow in WAP 

The transactions utilise a variety of transport schemes. For example, the MMS User Agent originates an MM by 
sending a M-Send.req to the MMS Relay by use of a WSP/HTTP POST method. This operation transmits the required 
data from the MMS User Agent to the MMS Relay as well as provides a transactional context for the resulting 
M-Send.conf response. 

The MMS Relay uses WAP PUSH technology to send the M-Notification.ind to the MMS User Agent. This is how the 
MMS User Agent is informed of MMs available for retrieval. Included, as a data component, is the URI of the MM that 
the MMS User Agent is to use for the retrieval. 

The retrieval activity is performed by the MMS User Agent using the WSP/HTTP GET method on the URI provided. 
The fetch of the URI returns the M-retrieve.conf which contains the actual MM to be presented to the user. 

The MMS Relay may request information that would permit to know that the MM was actually received by the MMS 
User Agent. One approach would be for a distinct M-Acknowledge.ind to be passed from the MMS User Agent to the 
MMS Relay. 
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The MMS Relay is responsible for supporting an optional delivery report back to the originating MMS User Agent. 
Based upon possible delivery outcomes, the MMS Relay would again utilise WAP PUSH technology to inform the 
MMS User Agent with the M-Delivery.ind message. 



7.4 Terminal Capability Negotiation 



WAP provides a mechanism to inform an origin server, such as the MMS Relay, of the capabilities of the MMS User 
Agent. This is known as User Agent Profile (UAProf) [25]. It provides information about the characteristics of the 
display (e.g. size, color support, bit depth), supported content types and network limitations (e.g. max message size). 

The UAProf data is encoded in an RDF [26] data description language. It is conveyed, possibly indirectly, when the 
MMS User Agent performs a WSP/HTTP operation, such as a GET, to an origin server. It is up to the origin server to 
decode the RDF data, extracting any needed device characteristics, to guide the content generation or filtering operation 
it performs before returning data to the MMS User Agent. 

For MMS, the MMS Relay should be able to utilise the capability information to make adjustments to the delivered 
MM contents. For example, an MMS Relay may delete a message component if the content type was not supported by 
the terminal. Alternatively, the MMS Relay may adapt an unsupported content type to adjust the size, color depth or 
encoding format. WAP makes no requirements to the handling of this data or of any notifications that may be made to 
the user concerning such adjustments. 



7.5 MMS Message Contents 



The WAP work on MMS is defining a message encapsulation scheme to convey the data between the MMS User Agent 
and the MMS Relay. 

7.5.1 Multimedia Messages 

The MIME multipart technique is standard Internet technique to combine the email body and the attachments together. 
The WAP has a binary equivalent to this, referenced in [23] which can be used to combine multimedia objects in the 
multimedia messages together. This approach shall be used for messages between the MMS Relay and MMS User 
Agent which also include MM components. This includes the message send and retrieve. 

The use of the WAP binary multipart structure allows easy conversion between binary format and the Internet MIME 
multipart. In addition, the binary format allows efficient handling of the message especially in cases when some 
multimedia objects must be taken out of the structure. 

A special, application specific part should contain the MMS header information. This header information is used to 
provide the message type information as well as message-specific information. The proposed content type for this part 
is application/mmsheader and until registration within lANA, the interim content type shall be application/x- 
mmsheader. 

7.5.2 Other Messages 

Other MMS transactional messages utilise additional PDUs for multimedia message notification, acknowledgements 
and delivery reports. These messages are conveyed with messages that just utilise a content type proposed to be 
application/mmsheader. Until registration within lANA, the interim content type shall be application/x-mmsheader. 

7.6 MMS Presentation 

The rendering of an MM for a user is the ultimate objective of the MMS. This rendering operation is known as 
presentation. Various types of data may be used to drive the presentation. For example, the MM presentation may be 
based on a WML deck [27] or Synchronised Multimedia Integration Language (SMIL) [28] which includes links to 
other component elements in the multipart message. Other presentation models may include a simple text body with 
image attachments. WAP has not specified any specific requirements on MMS presentations. UAProf [25] content 
negotiation methods should be used for presentation method selection. 
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NOTE: In the future, it will be desirable to consider mobile-optimised presentation technologies. For example, 

WAP Forum and W3C have initiated work on a mobile-optimised version of SMIL that would be suitable 
for use in an MMS environment. 

7.7 MMS Security Model between MMS User Agent and MMS 



Relay 



No MMS-specific requirements are in place within the WAP Forum to support security mechanisms in the transactions 
between the MMS Relay and MMS User Agent. Existing schemes such as WTLS [29] and WIM [30] are available and 
other end-to-end techniques are under development. 
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Annex A (Informative): 

Examples of MMS architectural implementations 



A.1 Introduction 



This informative annex is intended to provide architectural examples based on the general architecture as outlined in 
clause 4 to show implementations for different business models. The focus is upon the various MMS Relay - MMS 
Server scenarios, whereas the MMS Relay - MMS User Agent interface is assumed to be as stated in subclause 6.2. 
Each of the following subsubclauses provides only one possible scenario, however a combination could be feasible. 
Please note that each functional element should be understood as a logical entity and may be combined due to 
implementation reasons. 



A.2 Example of combined MMS-Relay/MMS-Server 

This scenario shows the case where the two logical entities, MMS Relay and MMS Server, are combined into a single 
physical entity. 
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Figure 9: Example of combined MMS-Relay/Server 
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A.3 Example of non-combined MMS-Relay and 
MMS-Server 
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Figure 10: Example of non-combined MMS-Relay and MMS-Server 

For the transfer of MMs between an MMS-Relay and an MMS-Server the use of SMTP and POP3[34]/IMAP4[35] or 
HTTP as illustrated in Figure 10 is identified as appropriate. 

If the protocol is SMTP for up- and download of MMs to the server, then it is identical to the one used between 
different MMS -Relays as specified in the subclause 6.6. 
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A.4 Example of MMS interaction with T.30 Facsimile 
Services 

Message 

MMS ^- -^^ Store 

server 





MMS ITU-T. 37 

Relay Fax 

Gateway 

Figure 11: Example of MMS interaction with Facsimile Services based on ITU-T.37 

For the transfer of facsimile data via store-and-forward mechanisms ITU-T.37 [31] procedures have been standardised. 
These are identified as appropriate in the MMS environment for the interworking with T.30 [32] facsimile services. 
What the relevant MMSE parts are supposed to look like for a T.37 approach is depicted in figure 11. The MMS Relay 
interfaces with a T.37 Fax Gateway. For the Gateway's communication with the MMS Relay the appropriate protocol is 
SMTP. I.e., the protocol to be used on the interface between MMS-Relay and the Fax GW is identical to the one used 
between different MMS -Relays as specified in subclause 6.6. 

NOTE: The MMS Relay - MMS Server interface is not in the scope of this subclause but described in A.3. 

Towards the PSTN the Fax-GW terminates the T.30 facsimile protocol. Mobile terminated fax data will be converted 
into TIFF [3 6] image format and forwarded to the MMS Relay as an attachment in an IETF internet email. In case of 
mobile originated fax messages the Fax-GW receives a written email provided with the receiver' s fax number from the 
MMS Relay. Depending on the functions of the Fax-GW this email may contain plain text only or additional 
attachments, too. Although T.37 requires only TIFF format support there are Fax-GWs out on the market that permit 
many different formats to be included. 



A.5 Example of MMS interaction with 2G/3G Voice 
Mailboxes 

MMS interaction with voice mailbox systems should be performed on a non-realtime basis. Figure 12 illustrates an 
example architecture for the incorporation of voice mailboxes. 
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Figure 12: First Example of MMS interaction with 2G/3G Voice Mailbox based on VPIM 

The Voice Profile for Internet Mail Version 2, VPIMv2, provides format extensions for MIME supporting the 
transmission of voice messages over standard Internet E-Mail systems. The VPIM concept was developed by the 
Electronic Messaging Association (EMA). After VPIMv2 had been reviewed by the IETF it became RFC 2421 [33]. 

The VPIM specification allows voice records to be MIME encapsulated and sent as Internet mail attachments via SMTP 
or retrieved as Internet mail attachments via P0P3 [34] or IMAP4[35]. The MIME type used for voice messages is 
"audio/*". 

For the interaction of MMS with voice mailboxes, either the voice mailbox forwards received voice records as VPIM 
messages via SMTP to the MMS relay. This implies that voice messages' download is always done via the MMS 
service. In this case the protocol to be used on the interface between MMS-Relay and the voice mailbox is SMTP and 
thus identical to the one used between different MMS -Relays as specified in subclause 6.6. 

Alternatively, the MMS Relay may poll the voice mailbox via P0P3 or IMAP4 for new messages received. Messages 
the user wants to retrieve via the MMS service can then be downloaded via POP3/IMAP4 from the voice mailbox to the 
MMS Relay from where they are delivered to the MMS User Agent. This enables the user to do both, retrieve voice 
messages via today's realtime voice mail services or as an MM. In any case it is expected that the voice mailbox is still 
the owner of the message and as a consequence responsible for the storage. 

As an alternative the MMS interworking with a 2G/3G Voice Mailbox System could be envisaged via an HTTP 
interface as depicted in figure 13. 
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Figure 13: Second example of MMS interaction with 2G/3G Voice Mailbox based on HTTP 
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Messaging 



SMTP 





1 



Forwarding Mail 
Transfer Agent 



MMS 
Relay 



SMTP 

or 

POPS/ 

IMAP4 




Message 
Store 



E-Mail 
Server 



Figure 14: Example of interaction with Internet E-Mail messaging 

In this architecture the server will be an E-Mail server providing post office services which are accessible e.g. via POPS 
[34] or IMAP[35] for Internet E-Mail retrieval in the MMSE or are accessible to the Relay using SMTP. The MMS 
Relay will sent MMs that are to be transmitted as Internet E-Mail via SMTP. 

In the case of retrieval and sending of MMs from and to the Internet Email service is done via SMTP, the protocol to be 
used on the interface between MMS -Relay and the Mail Transfer Agent, MT A/Email Server is identical to the one used 
between different MMS -Relays as specified in subclause 6.6. 
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A.7 Example of interaction with Short IVIessage Service, 
SIVIS 




MMS SMSC ^^ 

Relay 

Figure 15: Example of MMS interaction with SMS based on SMPP 

In the light of the WAP standardisation the SMPP Developer's Forum has defined a common standard for sending and 
receiving Short Messages via an SMSC, the Short Message Peer-to-Peer Protocol, SMPP [37]. 

Depending on the SMSC manufacturer the MMS Relay either can be directly connected to the SMSC (as shown in 
figure 15) or an additional SMS-Gateway has to be added. In the latter case the SMS-GW has to be located between the 
MMS Relay and the SMSC and provides the mapping of SMPP to the manufacturer's proprietary SMSC access 
protocol. 



ETSI 



3G TS 23.140 version 3.0.1 Release 1999 25 



ETSI TS 123 140 V3.0.1 (2000-03) 



Annex B (Informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


OR 


Rev 


Subject/Comment 


Old 


New 


15/03/00 


T#7 


TP-000028 






New 


2.0.0 


3.0.0 












Editorial change by IVICC 


3.0.0 


3.0.1 



















































ETSI 



3G TS 23.140 version 3.0.1 Release 1999 26 



ETSI TS 123 140 V3.0.1 (2000-03) 



History 



Document history 


V3.0.1 


March 2000 


Publication 



























ETSI 



